feat(amf): add native AMD AMF encoder - #342

I've quickly tested the latest build and the streaming got broken on AV1/HEVC/H264. The interesting thing is that Artemis told me my GPU wasn't capable of HDR when I started the stream. I only got a purple screen when the stream started. Sorry for not providing the log but I couldn't since I was in a hurry.

@RunAway189 Thanks for testing and reporting, that's exactly the kind of report that's useful even without a log.

I tried to reproduce on an RX 7900 XT (AMF 1.5.2.0, Moonlight 6.1.0, 1080p120 @ 50 Mbps) and could not. What passed here on the current head: AV1, HEVC and H.264 in SDR, plus AV1 and HEVC with HDR actually negotiated (Sent HDR mode: true), all with zero AMF warnings or fatals. So whatever you hit is either configuration-specific or hardware and driver specific, and I need a bit more to chase it.

What would help most, in rough order:

1. The host log. C:\Program Files\Apollo\config\logs\ (newest file), or Web UI → Troubleshooting → Logs. If you can set min_log_level = debug before reproducing, even better, the encoder probe results and the colorspace it selected both land in there.
2. GPU model and Adrenalin driver version.
3. Do you stream to a virtual display? (Settings → Audio/Video → virtual display, or virtual_display_mode in the config.) I reproduced a separate problem tonight where the Sunshine virtual display driver intermittently fails to respond and the host then never finishes starting. A stream against that would come up broken regardless of codec, which matches "all three codecs" better than an encoder bug does. If you're on a virtual display, that's my leading suspicion.
4. Was HDR enabled in the client when it told you the GPU wasn't capable?

Also useful as a bisect: the previous tester build is still up with the same install steps, native-amf-stable2-20260723. If that one streams fine and the newest doesn't, that narrows it to a handful of commits and I'll find it quickly. If both are broken the same way, it's not from the recent changes and the log becomes the fastest path.

One thing your report already earned regardless: reviewing the newest changes under suspicion turned up a real latent bug of my own, a dropped submission could withhold the frame counter and, under conditions that persist, freeze the stream instead of just skipping a frame. That's reverted on the branch now.

This issue you have could also be related to my separate VDD PR.

From my side this is stable enough to be worth a review, so I would like to hand it over for your input on the approach and the scope before it goes any further.

I am stopping active work on it here. Development on main moves quickly enough that keeping this branch rebased and re-measured against it has become most of the effort, and someone closer to main is better placed to carry it from this point.

State of things: everything is one commit against 1.18.3-beta.2. Three smaller fixes that came out of this work are separate pull requests, none of them AMD specific: #351 (virtual display recovery stalling startup), #352 (branch builds reporting version 0.0.0), #353 (PIN-stdin pairing never completing). A tester build is linked in the description for anyone who wants to try it on other AMD hardware.

@RunAway189 Thanks for testing and reporting, that's exactly the kind of report that's useful even without a log.

I tried to reproduce on an RX 7900 XT (AMF 1.5.2.0, Moonlight 6.1.0, 1080p120 @ 50 Mbps) and could not. What passed here on the current head: AV1, HEVC and H.264 in SDR, plus AV1 and HEVC with HDR actually negotiated (Sent HDR mode: true), all with zero AMF warnings or fatals. So whatever you hit is either configuration-specific or hardware and driver specific, and I need a bit more to chase it.

What would help most, in rough order:

1. **The host log.** `C:\Program Files\Apollo\config\logs\` (newest file), or Web UI → Troubleshooting → Logs. If you can set `min_log_level = debug` before reproducing, even better, the encoder probe results and the colorspace it selected both land in there.

2. **GPU model and Adrenalin driver version.**

3. **Do you stream to a virtual display?** (Settings → Audio/Video → virtual display, or `virtual_display_mode` in the config.) I reproduced a _separate_ problem tonight where the Sunshine virtual display driver intermittently fails to respond and the host then never finishes starting. A stream against that would come up broken regardless of codec, which matches "all three codecs" better than an encoder bug does. If you're on a virtual display, that's my leading suspicion.

4. **Was HDR enabled in the client** when it told you the GPU wasn't capable?

Also useful as a bisect: the previous tester build is still up with the same install steps, native-amf-stable2-20260723. If that one streams fine and the newest doesn't, that narrows it to a handful of commits and I'll find it quickly. If both are broken the same way, it's not from the recent changes and the log becomes the fastest path.

One thing your report already earned regardless: reviewing the newest changes under suspicion turned up a real latent bug of my own, a dropped submission could withhold the frame counter and, under conditions that persist, freeze the stream instead of just skipping a frame. That's reverted on the branch now.

Hi, I've just tested the latest one and I got the same results. I'm going to attach the debug log and answer to your questions:

2. ASUS Prime RX 9070 XT with Adrenalin Edition 26.6.4 Driver

3. Yes, I've just left everything on default like the stable build of Vibepollo, the only thing that I've checked in that section is the Vulkan HDR layer for virtual displays. I also tried to uncheck it to see if that one was the culprit but it wasn't the case.

4. The client tested was my Odin 2 Portal and in my Artemide settings I've both checked to use a virtual display and to use the HDR like I do daily with Vibepollo.

Here's the log:

sunshine-20260725-141151-693.log

Found it in the log, thanks for the debug capture. Every SDR probe succeeds and every 10-bit HDR probe fails:

Color coding: HDR (Rec. 2020 + SMPTE 2084 PQ)   Color depth: 10-bit
AMF: encoder Init failed with the requested encode settings, error: 10

Error 10 is AMF_NOT_SUPPORTED, so the host concludes it has no HDR capability, which is what Artemis then told you.

The trigger is PreAnalysis combined with 10-bit. Your config has amd_rc = hqcbr and amd_preanalysis = enabled rather than the defaults, and HQCBR forces PreAnalysis on regardless of that second setting. This is not specific to your RDNA4 card: my earlier runs on an RX 7900 XT rejected HDR probes on QVBR, HQVBR and HQCBR, and on no other rate control mode.

Set rate control to vbr_latency and leave PreAnalysis off. HDR should negotiate normally.

I guess we could automatically set the encoder to drop PreAnalysis on 10-bit sessions instead of failing init and losing HDR entirely. I have stopped active work on this branch, so I am leaving that to whoever picks it up, and this comment is here so the cause is on record. When the next stable version is merged, I might rebase and also include this.

From my side this is stable enough to be worth a review, so I would like to hand it over for your input on the approach and the scope before it goes any further.

I am stopping active work on it here. Development on main moves quickly enough that keeping this branch rebased and re-measured against it has become most of the effort, and someone closer to main is better placed to carry it from this point.

State of things: everything is one commit against 1.18.3-beta.2. Three smaller fixes that came out of this work are separate pull requests, none of them AMD specific: #351 (virtual display recovery stalling startup), #352 (branch builds reporting version 0.0.0), #353 (PIN-stdin pairing never completing). A tester build is linked in the description for anyone who wants to try it on other AMD hardware.

There was a lot of refactoring work done by Terra Ultra to fix longstanding issues, but at this point I can maintain the code from here. I will handle the bug fixes and security issues from here. I appreciate you spending the time to do this for AMD users.

As for everyone else, if you notice an AMD specific problem please open an issue up with logs and I will take over the bug fixes from here.

Found it in the log, thanks for the debug capture. Every SDR probe succeeds and every 10-bit HDR probe fails:

Color coding: HDR (Rec. 2020 + SMPTE 2084 PQ)   Color depth: 10-bit
AMF: encoder Init failed with the requested encode settings, error: 10

Error 10 is AMF_NOT_SUPPORTED, so the host concludes it has no HDR capability, which is what Artemis then told you.

The trigger is PreAnalysis combined with 10-bit. Your config has amd_rc = hqcbr and amd_preanalysis = enabled rather than the defaults, and HQCBR forces PreAnalysis on regardless of that second setting. This is not specific to your RDNA4 card: my earlier runs on an RX 7900 XT rejected HDR probes on QVBR, HQVBR and HQCBR, and on no other rate control mode.

Set rate control to vbr_latency and leave PreAnalysis off. HDR should negotiate normally.

I guess we could automatically set the encoder to drop PreAnalysis on 10-bit sessions instead of failing init and losing HDR entirely. I have stopped active work on this branch, so I am leaving that to whoever picks it up, and this comment is here so the cause is on record. When the next stable version is merged, I might rebase and also include this.

I've just tested and confirmed your theory: leaving vbr_latency and AMF PreAnalysis off fixed my streaming issue. The HDR is back and everything is as smooth as always. That said, in my opinion the new modes — QVBR, HQVBR, and HQCBR — offer better image quality compared to vbr_latency. I don't know which of you will be handling this issue, but if you need any further tests to fix it, just let me know. I'll be here to help both of you, @RamazanKara @Nonary.

Also, I tried streaming without HDR for the first time on my Odin 2 Portal, and what surprised me the most was how much clearer the text looked on Windows. I'm not sure why, but when HDR is enabled, all the text seems to have a white outline, making everything look "blurrier" and less crisp than when HDR is off. I don't know if that makes sense, but that's what I found. It happens both with this test version and the official Vibepollo build.

Thanks for the substantial work on the native AMD AMF encoder.

This is a friendly provenance reminder, not a challenge to Vibepollo’s right to reuse the code. We understand that both Foundation Sunshine and Vibepollo are released under GPLv3, and that GPLv3 permits copying, modification, and redistribution under its terms.

During our review, we noticed that several additions in:

src/amf/amf_d3d11.cpp

closely match the earlier Foundation commit:

AlkaidLab/foundation-sunshine@3340d28

This includes the LOWLATENCY_MODE / INPUT_QUEUE_SIZE changes, the related rationale comments, and the reference to AlkaidLab/foundation-sunshine#666. That Foundation commit predates this PR.

The current PR description says “Based on 1.18.3-beta.2”, but does not mention the Foundation implementation or commit as a source.

Since both projects are GPLv3-licensed, we are not disputing the legality of reusing the code. We are only asking for the provenance to be made clear and for any applicable copyright, license, and modification notices to remain preserved.

If these parts were derived from Foundation, could you please update the PR or commit documentation with a source reference such as:

Based on AlkaidLab/foundation-sunshine commit 3340d28 (ClassicOldSong#666), modified for Vibepollo by Ramazan Kara, and released under GPLv3.

If the implementation was developed independently, please clarify the common provenance and differences so that the contribution history remains accurate.

Thanks for helping keep the licensing and contribution history clear.

===========================
PS:
Finally, we would like to add that we imagine you, just like us, have invested a great deal of time and effort in development and testing. Thank you all for your contributions and for bringing new strength to the streaming community.

At the same time, this reminds us that AI still needs human guidance in this kind of work. Guiding and reviewing AI is not only a responsibility that developers have toward the community; it is also an acknowledgment of the community members who help test the software and report problems.

We will continue maintaining the AMD-related functionality on our side. If we make any new discoveries in the future, we would be happy to share our experience and learn from each other.

=====================
Finally, we would like to add that we imagine you, just like us, have invested a great deal of time and effort in development and testing. Thank you all for your contributions and for bringing new strength to the streaming community.

At the same time, this reminds us that AI still needs human guidance in this kind of work. Guiding and reviewing AI is not only a responsibility that developers have toward the community; it is also an acknowledgment of the community members who help test the software and report problems.

We will continue maintaining the AMD-related functionality on our side. If we make any new discoveries in the future, we would be happy to share our experience and learn from each other.

This is AI generated code, I can't prove it was taken from sunshine foundation or not. @RamazanKara would have to clarify that and if so, I will properly accredit the sourcing.

@Yundi339 You are right, and thank you for raising it directly and with the specific commit.

I checked rather than taking it on faith. Comparing 3340d28 against current master, 37 comment lines added by that commit appear verbatim in this tree: 25 in src/amf/amf_d3d11.cpp and 12 in src/amf/amf_config.h. That is broader than the two blocks you pointed at, and it includes narrative that could not arise independently, such as "AV1 was unaffected precisely because no AV1 branch existed here" and "Adrenalin 26.5.x on HEVC: video stalls while audio keeps flowing". The surrounding code was adapted rather than copied line for line, since this version routes those properties through verified setters, but the design decision and the reasoning are yours.

So to answer @Nonary directly: yes, those parts are derived from Foundation. The attribution should have been there from the start and its absence is on me as the submitter.

I have opened #382, which adds a provenance notice to the header of both files naming the commit, the issue, qiin2333 as the author, and the GPLv3 license both projects share. If you would prefer different wording or want the notice placed at the specific call sites instead of the file headers, say so and I will change it.

@Nonary when this reaches release notes, could Foundation Sunshine be credited for the AMD default handling, and could I be listed for the native encoder work alongside it? Foundation first, since that part predates mine.

On your postscript: it is a fair point and this is a concrete instance of it. This work was produced with heavy AI assistance, and provenance is precisely the sort of thing that disappears when nobody stops to ask where a rationale comment came from. Reviewing output for correctness is not the same as reviewing it for origin, and I did the first and not the second. I appreciate you handling it as a reminder rather than an accusation, and the offer to share findings goes both ways. The HDR failure under PreAnalysis discussed earlier in this thread is one you may well hit on RDNA4 too.

They’ve only requested that the copyright and license notices be preserved in the source files and that the GPL’s license obligations are followed.

I don’t think crediting the original project in the release notes is necessary, and it would be excessive as a general practice. Many open source projects depend on GPL-licensed software, and release notes would quickly become an endless list of acknowledgements if that were expected.

To me, release notes are primarily for informing users about changes and highlighting noteworthy contributions. Attribution to upstream projects is typically handled through the preserved copyright notices, license files, and other licensing requirements, unless the project is largely a fork or the maintainers have specifically requested additional acknowledgement.

I’m here, I’m here, I just saw the emails 😂

You’re right, I should have clarified this earlier.
There’s no need for anything overly formal — adding a note or link in the PR description (not the title) about the source/derivation is enough.

@RamazanKara There is no need to explain it in the comments. That would just pollute the codebase. Unless we become good enough to publish an RFC specifically dedicated to AMD encoder handling.

The HDR failure under PreAnalysis discussed earlier in this thread is one you may well hit on RDNA4 too.

@RamazanKara Got it, if we run into this issue, we’ll take a look at it.

For AMD, the situation on Foundation is quite interesting. The community had been asking for better AMD support for quite some time, so auther @qiin2333 actually bought an AMD GPU just for testing. That was really impressive.

Honestly, AMD is a bit mysterious for developers. Even with AI assistance, different developers can have different understandings of how the AMD encoder behaves. A single AMD GPU is simply not enough to cover all the cases. Right now, we mainly rely on feedback from the community and gradually add fixes based on real-world reports.

Especially because AMD keeps adding new features through driver updates, the AMD user base is split into different groups with different driver behaviors.

For example, there was an HDR-related issue where users did not enable HDR, but the output was still overexposed. After investigation, we found that some AMD drivers enabled 10-bit output by default, so we added detection for that case.

Done. The provenance note with the commit link is now in this PR's description, and I closed #382 since file headers were more than anyone asked for. Release-notes point withdrawn too, the preserved notices cover it.

Buying a GPU just to chase community reports is dedication, hats off to qiin2333. If we hit anything new on the AMD side it will land in your tracker.